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ABSTRACT 

In  unit  testing,  a  program  is  decomposed  into  units  which 
are  collections  of  functions.  A  part  of  unit  can  be  tested 
by  generating  inputs  for  a  single  entry  function.  The  en¬ 
try  function  may  contain  pointer  arguments,  in  which  case 
the  inputs  to  the  unit  are  memory  graphs.  The  paper  ad¬ 
dresses  the  problem  of  automating  unit  testing  with  mem¬ 
ory  graphs  as  inputs.  The  approach  used  builds  on  previous 
work  combining  symbolic  and  concrete  execution,  and  more 
specifically,  using  such  a  combination  to  generate  test  in¬ 
puts  to  explore  all  feasible  execution  paths.  The  current 
work  develops  a  method  to  represent  and  track  constraints 
that  capture  the  behavior  of  a  symbolic  execution  of  a  unit 
with  memory  graphs  as  inputs.  Moreover,  an  efficient  con¬ 
straint  solver  is  proposed  to  facilitate  incremental  generation 
of  such  test  inputs.  Finally,  CUTE,  a  tool  implementing  the 
method  is  described  together  with  the  results  of  applying 
CUTE  to  real-world  examples  of  C  code. 

Categories  and  Subject  Descriptors:  D.2.5  [Software 
Engineering]:  Testing  and  Debugging 

General  Terms:  Reliability, Verification 

Keywords:  concolic  testing,  random  testing,  explicit  path 
model-checking,  data  structure  testing,  unit  testing,  testing 
C  programs. 

1.  INTRODUCTION 

Unit  testing  is  a  method  for  modular  testing  of  a  pro¬ 
grams’  functional  behavior.  A  program  is  decomposed  into 
units,  where  each  unit  is  a  collection  of  functions,  and  the 
units  are  independently  tested.  Such  testing  requires  speci¬ 
fication  of  values  for  the  inputs  (or  test  inputs)  to  the  unit. 
Manual  specification  of  such  values  is  labor  intensive  and 
cannot  guarantee  that  all  possible  behaviors  of  the  unit  will 
be  observed  during  the  testing. 

In  order  to  improve  the  range  of  behaviors  observed  (or 
test  coverage),  several  techniques  have  been  proposed  to  au¬ 
tomatically  generate  values  for  the  inputs.  One  such  tech¬ 


nique  is  to  randomly  choose  the  values  over  the  domain  of 
potential  inputs  [4,8,10,22].  The  problem  with  such  random 
testing  is  two  fold:  first,  many  sets  of  values  may  lead  to  the 
same  observable  behavior  and  are  thus  redundant,  and  sec¬ 
ond,  the  probability  of  selecting  particular  inputs  that  cause 
buggy  behavior  may  be  astronomically  small  [21]. 

One  approach  which  addresses  the  problem  of  redundant 
executions  and  increases  test  coverage  is  symbolic  execu¬ 
tion  [1,3,9,23,24,27,28,30].  In  symbolic  execution,  a  pro¬ 
gram  is  executed  using  symbolic  variables  in  place  of  con¬ 
crete  values  for  inputs.  Each  conditional  expression  in  the 
program  represents  a  constraint  that  determines  an  execu¬ 
tion  path.  Observe  that  the  feasible  executions  of  a  program 
can  be  represented  as  a  tree,  where  the  branch  points  in  a 
program  are  internal  nodes  of  the  tree.  The  goal  is  to  gen¬ 
erate  concrete  values  for  inputs  which  would  result  in  differ¬ 
ent  paths  being  taken.  The  classic  approach  is  to  use  depth 
first  exploration  of  the  paths  by  backtracking  [15].  Unfor¬ 
tunately,  for  large  or  complex  units,  it  is  computationally 
intractable  to  precisely  maintain  and  solve  the  constraints 
required  for  test  generation. 

To  the  best  of  our  knowledge,  Larson  and  Austin  were 
the  first  to  propose  combining  concrete  and  symbolic  exe¬ 
cution  [17].  In  their  approach,  the  program  is  executed  on 
some  user-provided  concrete  input  values.  Symbolic  path 
constraints  are  generated  for  the  specific  execution.  These 
constraints  are  solved,  if  feasible,  to  see  whether  there  are 
potential  input  values  that  would  have  led  to  a  violation 
along  the  same  execution  path.  This  improves  coverage 
while  avoiding  the  computational  cost  associated  with  full¬ 
blown  symbolic  execution  which  exercises  all  possible  exe¬ 
cution  paths. 

Godefroid  et  al.  proposed  incrementally  generating  test 
inputs  by  combining  concrete  and  symbolic  execution  [11], 
In  Godefroid  et  al.’s  approach,  during  a  concrete  execution, 
a  conjunction  of  symbolic  constraints  along  the  path  of  the 
execution  is  generated.  These  constraints  are  modified  and 
then  solved,  if  feasible,  to  generate  further  test  inputs  which 
would  direct  the  program  along  alternative  paths.  Specifi¬ 
cally,  they  systematically  negate  the  conjuncts  in  the  path 
constraint  to  provide  a  depth  first  exploration  of  all  paths 
in  the  computation  tree.  If  it  is  not  feasible  to  solve  the 
modified  constraints,  Godefroid  et  al.  propose  simply  sub¬ 
stituting  random  concrete  values. 

A  challenge  in  applying  Godefroid  et  al.’s  approach  is  to 
provide  methods  which  extract  and  solve  the  constraints 
generated  by  a  program.  This  problem  is  particularly  com¬ 
plex  for  programs  which  have  dynamic  data  structures  using 
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pointer  operations.  For  example,  pointers  may  have  aliases. 
Because  alias  analysis  may  only  be  approximate  in  the  pres¬ 
ence  of  pointer  arithmetic,  using  symbolic  values  to  precisely 
track  such  pointers  may  result  in  constraints  whose  satisfac¬ 
tion  is  undecidable.  This  makes  the  generation  of  test  in¬ 
puts  by  solving  such  constraints  infeasible.  In  this  paper,  we 
provide  a  method  for  representing  and  solving  approximate 
pointer  constraints  to  generate  test  inputs.  Our  method  is 
thus  applicable  to  a  broad  class  of  sequential  programs. 

The  key  idea  of  our  method  is  to  represent  inputs  for  the 
unit  under  test  using  a  logical  input  map  that  represents  all 
inputs,  including  (finite)  memory  graphs,  as  a  collection  of 
scalar  symbolic  variables  and  then  to  build  constraints  on 
these  inputs  by  symbolically  executing  the  code  under  test. 

We  first  instrument  the  code  being  tested  by  inserting 
function  calls  which  perform  symbolic  execution.  We  then 
repeatedly  run  the  instrumented  code  as  follows.  The  logi¬ 
cal  input  map  X  is  used  to  generate  concrete  memory  input 
graphs  for  the  program  and  two  symbolic  states,  one  for 
pointer  values  and  one  for  primitive  values.  The  code  is  run 
concretely  on  the  concrete  input  graph  and  symbolically  on 
the  symbolic  states,  collecting  constraints  (in  terms  of  the 
symbolic  variables  in  the  symbolic  state)  that  characterize 
the  set  of  inputs  that  would  (likely)  take  the  same  execution 
path  as  the  current  execution  path.  As  in  [11],  one  of  the 
collected  constraints  is  negated.  The  resulting  constraint 
system  is  solved  to  obtain  a  new  logical  input  map  X'  that 
is  similar  to  X  but  (likely)  leads  the  execution  through  a 
different  path.  We  then  set  X  =  1'  and  repeat  the  process. 
Since  the  goal  of  this  testing  approach  is  to  explore  feasi¬ 
ble  execution  paths  as  much  as  possible,  it  can  be  seen  as 
Explicit  Path  Model-Checking. 

An  important  contribution  of  our  work  is  separating 
pointer  constraints  from  integer  constraints  and  keeping  the 
pointer  constraints  simple  to  make  our  symbolic  execution 
light-weight  and  our  constraint  solving  procedure  not  only 
tractable  but  also  efficient.  The  pointer  constraints  are  con¬ 
ceptually  simplified  using  the  logical  input  map  to  replace 
complex  symbolic  expressions  involving  pointers  with  sim¬ 
ple  symbolic  pointer  variables  (while  maintaining  the  precise 
pointer  relations  in  the  logical  input  map).  For  example,  if 
p  is  an  input  pointer  to  a  struct  with  a  field  f,  then  a 
constraint  on  p->f  will  be  simplified  to  a  constraint  on  /o, 
where  fo  is  the  symbolic  variable  corresponding  to  the  input 
value  p->f .  Although  this  simplification  introduces  some  ap¬ 
proximations  that  do  not  precisely  capture  all  executions,  it 
results  in  simple  pointer  constraints  of  the  form  x  =  y  or 
x  ^  y,  where  x  and  y  are  either  symbolic  pointer  variables 
or  the  constant  NULL.  These  constraints  can  be  efficiently 
solved,  and  the  approximations  seem  to  suffice  in  practice. 

We  implemented  our  method  in  a  tool  called  CUTE 
(Concolic  Unit  Testing  Engine,  where  Concolic  stands 
for  cooperative  Concrete  and  symbolic  execution).  CUTE 
is  available  at  http://osl.cs.uiuc.edu/~ksen/cute/. 
CUTE  implements  a  solver  for  both  arithmetic  and  pointer 
constraints  to  incrementally  generate  test  inputs.  The  solver 
exploits  the  domain  of  this  particular  problem  to  implement 
three  novel  optimizations  which  help  to  improve  the  testing 
time  by  several  orders  of  magnitude.  Our  experimental  re¬ 
sults  confirm  that  CUTE  can  efficiently  explore  paths  in  C 
code,  achieving  high  branch  coverage  and  detecting  bugs.  In 
particular,  it  exposed  software  bugs  that  result  in  assertion 
violations,  segmentation  faults,  or  infinite  loops. 


typedef  struct  cell  { 
int  v; 

struct  cell  *next; 

}  cell; 

int 

f(int  v)  { 

return  2*v  +  1 ; 

} 

int 

testme(cell  *p,  int  x)  { 
if  (x  >  0) 

if  (p  ! =  NULL) 

if  (f(x)  ==  p— >v) 
if  (p->next  ==  p) 

ERROR ; 
return  0; 

} 

Figure  1:  Example  C  code  and  inputs  that  CUTE 
generates  for  testing  the  function  testme 


This  paper  presents  two  case  studies  of  testing  code  using 
CUTE.  The  first  study  involves  the  C  code  of  the  CUTE 
tool  itself.  The  second  case  study  found  two  previously  un¬ 
known  errors  (a  segmentation  fault  and  an  infinite  loop) 
in  SGLIB  [25],  a  popular  C  data  structure  library  used  in 
a  commercial  tool.  We  reported  the  SGLIB  errors  to  the 
SGLIB  developers  who  fixed  them  in  the  next  release. 

2.  EXAMPLE 

We  use  a  simple  example  to  illustrate  how  CUTE  performs 
testing.  Consider  the  C  function  testme  shown  in  Figure  1. 
This  function  has  an  error  that  can  be  reached  given  some 
specific  values  of  the  input.  In  a  narrow  sense,  the  input 
to  testme  consists  of  the  values  of  the  arguments  p  and 
x.  However,  p  is  a  pointer,  and  thus  the  input  includes  the 
memory  graph  reachable  from  that  pointer.  In  this  example, 
the  graph  is  a  list  of  cell  allocation  units. 

For  the  example  function  testme,  CUTE  first  non- 
randomly  generates  NULL  for  p  and  randomly  generates  236 
for  x,  respectively.  Figure  1  shows  this  input  to  testme.  As 
a  result,  the  first  execution  of  testme  takes  the  then  branch 
of  the  first  if  statement  and  the  else  branch  of  the  second 
if.  Let  po  and  xo  be  the  symbolic  variables  representing  the 
values  of  p  and  x,  respectively,  at  the  beginning  of  the  ex¬ 
ecution.  CUTE  collects  the  constraints  from  the  predicates 
of  the  branches  executed  in  this  path:  xo  >  0  (for  the  then 
branch  of  the  first  if)  and  po  =  NULL  (for  the  else  branch  of 
the  second  if).  The  predicate  sequence  (*o  >  0,po  =  NULL) 
is  called  a  path  constraint. 

CUTE  next  solves  the  path  constraint  ( xo  >  0,po  ^ 
NULL),  obtained  by  negating  the  last  predicate,  to  drive 
the  next  execution  along  an  alternative  path.  The  solu¬ 
tion  that  CUTE  proposes  is  (po  non-NULL,  xo  i— >  236}, 
which  requires  that  CUTE  make  p  point  to  an  allocated  cell 
that  introduces  two  new  components,  p->v  and  p->next,  to 
the  reachable  graph.  Accordingly,  CUTE  randomly  gen¬ 
erates  634  for  p->v  and  non-randomly  generates  NULL  for 
p->next,  respectively,  for  the  next  execution.  In  the  sec¬ 
ond  execution,  testme  takes  the  then  branch  of  the  first 
and  the  second  if  and  the  else  branch  of  the  third  if. 
For  this  execution,  CUTE  generates  the  path  constraint 
(xo  >  0,po  ^  NULL,  2  •  *0  +  1  ^  to),  where  po,  Vo,  n0, 
and  xo  are  the  symbolic  values  of  p,  p->v,  p->next,  and 
x,  respectively.  Note  that  CUTE  computes  the  expression 


2  •  *o  +  1  (corresponding  to  the  execution  of  f)  through  an 
inter-procedural,  dynamic  tracing  of  symbolic  expressions. 

CUTE  next  solves  the  path  constraint  (xo  >  0,Po  ^ 
NULL,  2-xo  +  l  =  Vo),  obtained  by  negating  the  last  predicate 
and  generates  Input  3  from  Figure  1  for  the  next  execution. 
Note  that  the  specific  value  of  xo  has  changed,  but  it  remains 
in  the  same  equivalence  class  with  respect  to  the  predicate 
where  it  appears,  namely  xo  >  0.  On  Input  3,  testme  takes 
the  then  branch  of  the  first  three  if  statements  and  the 
else  branch  of  the  fourth  if.  CUTE  generates  the  path 
constraint  (xo  >  0,po  yf  NULL,  2  •  xo  +  1  =  vo,po  ^  no).  This 
path  constraint  includes  dynamically  obtained  constraints 
on  pointers.  CUTE  handles  constraints  on  pointers  but  re¬ 
quires  no  static  alias  analysis.  To  drive  the  program  along 
an  alternative  path  in  the  next  execution,  CUTE  solves  the 
constraints  (xo  >  0,po  ^  NULL,  2  •  xo  +  1  =  vo,po  =  no)  and 
generates  Input  4  from  Figure  1.  On  this  input,  the  fourth 
execution  of  testme  reveals  the  error  in  the  code. 

3.  CUTE 

We  first  define  the  input  logical  input  map  that  CUTE 
uses  to  represent  inputs.  We  also  introduce  program  units 
of  a  simple  C-like  language  ( cf.  [20] ) .  We  present  how  CUTE 
instruments  programs  and  performs  concolic  execution.  We 
then  describe  how  CUTE  solves  the  constraints  after  every 
execution.  We  next  present  how  CUTE  handles  complex 
data  structures.  We  finally  discuss  the  approximations  that 
CUTE  uses  for  pointer  constraints. 

To  explore  execution  paths,  CUTE  first  instruments  the 
code  under  test.  CUTE  then  builds  a  logical  input  map  X  for 
the  code  under  test.  Such  a  logical  input  map  can  represent 
a  memory  graph  in  a  symbolic  way.  CUTE  then  repeatedly 
runs  the  instrumented  code  as  follows: 

1.  It  uses  the  logical  input  map  X  to  generate  a  concrete 
input  memory  graph  for  the  program  and  two  symbolic 
states,  one  for  pointer  values  and  another  for  primitive 
values. 

2.  It  runs  the  code  on  the  concrete  input  graph,  collect¬ 
ing  constraints  (in  terms  of  the  symbolic  values  in  the 
symbolic  state)  that  characterize  the  set  of  inputs  that 
would  take  the  same  execution  path  as  the  current  ex¬ 
ecution  path. 

3.  It  negates  one  of  the  collected  constraints  and  solves 
the  resulting  constraint  system  to  obtain  a  new  logical 
input  map  X'  that  is  similar  to  X  but  (likely)  leads  the 
execution  through  a  different  path.  It  then  sets  X  =  X' 
and  repeats  the  process. 

Conceptually,  CUTE  executes  the  code  under  test  both 
concretely  and  symbolically  at  the  same  time.  The  actual 
CUTE  implementation  first  instruments  the  source  code  un¬ 
der  test,  adding  functions  that  perform  the  symbolic  execu¬ 
tion.  CUTE  then  repeatedly  executes  the  instrumented  code 
only  concretely. 

3.1  Logical  Input  Map 

CUTE  keeps  track  of  input  memory  graphs  as  a  logical  in¬ 
put  map  X  that  maps  logical  addresses  to  values  that  are  ei¬ 
ther  logical  addresses  or  primitive  values.  This  map  symbol¬ 
ically  represents  the  input  memory  graph  at  the  beginning 
of  an  execution.  The  reason  that  CUTE  introduces  logical 
addresses  is  that  actual  concrete  addresses  of  dynamically 


allocated  cells  may  change  in  different  executions.  Also,  the 
concrete  addresses  themselves  are  not  necessary  to  repre¬ 
sent  memory  graphs;  it  suffices  to  know  how  the  cells  are 
connected.  Finally,  CUTE  attempts  to  make  consecutive 
inputs  similar,  and  this  can  be  done  with  logical  addresses. 
If  CUTE  used  the  actual  physical  addresses,  it  would  de¬ 
pend  on  malloc  and  free  (to  return  the  same  addresses) 
and  more  importantly,  it  would  need  to  handle  destructive 
updates  of  the  input  by  the  code  under  test:  after  CUTE 
generates  one  input,  the  code  changes  it,  and  CUTE  would 
need  to  know  what  changed  to  reconstruct  the  next  input. 

Let  N  be  the  set  of  natural  numbers  and  V  be  the  set 
of  all  primitive  values.  Then,  X :  N  — >  N  U  Y.  The  values 
in  the  domain  and  the  range  of  X  belonging  to  the  set  N 
represents  the  logical  addresses.  We  also  assume  that  each 
logical  address  l  £  N  has  a  type  associated  with  it.  A  type 
can  be  T  *  (a  pointer  of  type  T)  (where  T  can  be  primitive 
type  or  struct  type)  or  Tp  (a  primitive  type).  The  function 
typeOf(l)  returns  this  type.  Let  the  function  sizeOf(T)  re¬ 
turns  the  number  of  memory  cells  that  an  object  of  type  T 
uses.  If  typeOf(l)  is  T  *  and  X{1)  yfNULL,  then  the  sequence 
X(v), . . .  ,X(v  +  n—l)  stores  the  value  of  the  object  pointed 
by  the  logical  address  l  (each  element  in  the  sequence  repre¬ 
sents  the  content  of  each  cell  of  the  object  in  order),  where 
v  =  X(l)  and  n  =sizeOf( T).  This  representation  of  a  logi¬ 
cal  input  map  essentially  gives  a  simple  way  to  serialize  a 
memory  graph. 

We  illustrate  logical  inputs  on  an  example.  Recall  the  ex¬ 
ample  Input  3  from  Figure  1.  CUTE  represents  this  input 
with  the  following  logical  input:  (3, 1,3,0),  where  logical 
addresses  range  from  1  to  4.  The  first  value  3  corresponds 
to  the  value  of  p:  it  points  to  the  location  with  logical  ad¬ 
dress  3.  The  second  value  1  corresponds  to  x.  The  third 
value  corresponds  to  p->v  and  the  fourth  to  p->next  (0  rep¬ 
resents  NULL).  This  logical  input  encodes  a  set  of  concrete 
inputs  that  have  the  same  underlying  graph  but  reside  at  dif¬ 
ferent  concrete  addresses.  Similarly,  the  logical  input  map 
for  Input  4  from  Figure  1  is  (3, 1,  3,  3). 

3.2  Units  and  Program  Model 

A  unit  under  test  can  have  several  functions.  CUTE  re¬ 
quires  the  user  to  select  one  of  them  as  the  entry  function 
for  which  CUTE  generates  inputs.  This  function  in  turn  can 
call  other  functions  in  the  unit  as  well  as  functions  that  are 
not  in  the  unit  (e.g.,  library  functions).  The  entry  function 
takes  as  input  a  memory  graph,  a  set  of  all  memory  loca¬ 
tions  reachable  from  the  input  pointers.  We  assume  that 
the  unit  operates  only  on  this  input,  i.e.,  the  unit  has  no 
external  functions  (that  would,  for  example,  simulate  an  in¬ 
teractive  input  from  the  user  or  file  reading).  However,  a 
program  can  allocate  additional  memory,  and  the  execution 
then  operates  on  some  locations  that  were  not  reachable  in 
the  initial  state.  Given  an  entry  function,  CUTE  generates 
a  main  function  that  first  initializes  all  the  arguments  of 
the  function  by  calling  the  primitive  function  input  ()  (de¬ 
scribed  next)  and  then  calls  the  entry  function  with  these 
arguments.  The  unit  along  with  the  main  function  forms  a 
closed  program  that  CUTE  instruments  and  tests. 

We  describe  how  CUTE  works  for  a  simple  C-like  language 
shown  in  Figure  2.  START  represents  the  first  statement  of  a 
program  under  test.  Each  statement  has  an  optional  label. 
The  program  can  get  input  using  the  expression  input().  For 
simplicity  of  description,  we  assume  that  a  program  gets  all 


P  ::  =  Stmt*  Stmt  ::  =  [1 :  ]  S 
S  ::=  Ihs  < —  6  |  if  p  goto  V  \  START  |  HALT  |  ERROR 
Ihs  ::=v  |  *v 

e  ::=  v  j  &t>  |  *v  \  c  \  v  op  v  \  input( ) 
where  op  £  {+,  — ,  /,  .}, 

v  is  a  variable,  c  is  a  constant 
p  ::=  v  =  v\  v^v\v<v\v<v\v>v\v>v 


Figure  2:  Syntax  of  a  simple  C-like  language 


the  inputs  at  the  beginning  of  an  execution  and  the  number 
of  inputs  is  fixed.  CUTE  uses  the  CIL  framework  [20]  to 
convert  more  complex  statements  (with  no  function  calls) 
into  this  simplified  form  by  introducing  temporary  variables. 
For  example,  CIL  converts  **v  =  3  into  tl  =  *v;  *tl  = 
3  and  p[i]  =  q[j]  into  tl  =  q+j  ;  t2  =  p+i ;  *t2  =  *tl. 
Details  of  handling  of  function  calls  using  a  symbolic  stack 
are  discussed  in  Section  4. 

The  C  expression  denotes  the  address  of  the  variable 
v,  and  *v  denotes  the  value  of  the  address  stored  in  v.  In 
concrete  state,  each  address  stores  a  value  that  either  is 
primitive  or  represents  another  memory  address  {pointer). 

3.3  Instrumentation 

To  test  a  program  P,  CUTE  tries  to  explore  all  execution 
paths  of  P.  To  explore  all  paths,  CUTE  first  instruments 
the  program  under  test.  Then,  it  repeatedly  runs  the  in¬ 
strumented  program  P  as  follows: 

/ /  input:  P  is  the  instrumented  program  to  test 
/ /  depth  is  the  depth  of  bounded  DFS 

run_CUTE(P ,  depth) 

X  —  [  ];  h  =  (number  of  arguments  in  P)  +  1; 

completed= false;  branch  Jiist=[  ]; 

while  not  completed 
execute  P 

Before  starting  the  execution  loop,  CUTE  initializes  the 
logical  input  map  1  to  an  empty  map  and  the  variable  h  rep¬ 
resenting  the  next  available  logical  address  to  the  number  of 
arguments  to  the  instrumented  program  plus  one.  (CUTE 
gives  a  logical  address  to  each  argument  at  the  very  begin¬ 
ning.)  The  integer  variable  depth  specifies  the  depth  in  the 
bounded  DFS  described  in  Section  3.4. 

Figure  3  shows  the  code  that  CUTE  adds  during  instru¬ 
mentation.  The  expressions  enclosed  in  double  quotes  (“e”) 
represent  syntactic  objects.  We  describe  the  instrumenta¬ 
tion  for  function  calls  in  Section  4.  In  the  following  section, 
we  describe  the  various  global  variables  and  procedures  that 
CUTE  inserts. 

3.4  Concolic  Execution 

Recall  that  a  program  instrumented  by  CUTE  runs  con¬ 
cretely  and  at  the  same  time  performs  symbolic  computation 
through  the  instrumented  function  calls.  The  symbolic  exe¬ 
cution  follows  the  path  taken  by  the  concrete  execution  and 
replaces  with  the  concrete  value  any  symbolic  expression 
that  cannot  be  handled  by  our  constraint  solver. 

An  instrumented  program  maintains  at  the  runtime  two 
symbolic  states  A  and  V,  where  A  maps  memory  locations 
to  symbolic  arithmetic  expressions,  and  V  maps  memory  lo¬ 
cations  to  symbolic  pointer  expressions.  The  symbolic  arith¬ 
metic  expressions  in  CUTE  are  linear,  i.e.  of  the  form 


Before  Instrumentation 

After  Instrumentation 

/ /  program  start 

START 

global  vars  A.  —  P  —  path-C  =  M  =  [  ]; 
global  vars  i  =inputNumber—  0; 

START 

/ /  inputs 
v  < —  input ()', 

inputN umber  =  inputNumber-\- 1; 
initlnput  (Szv ,  inputN  umber)', 

/ /  inputs 
*v  < —  input ()', 

inputN  umber  =  inputNumber-\- 1; 
initlnput(v ,  inputN umber)', 

/ /  assignment 
v  <—  e; 

execute_symbolic($zv ,  “e” ) ; 
v  < —  e; 

/ /  assignment 
*v  < —  e; 

execute_symbolic(v ,  “e” ); 

*v  < —  e; 

/ /  conditional 
if  ( p )  goto  l 

evaluate.predicate  ( “p” ,  p) ; 
if  (p)  goto  l 

/ /  normal  termination 
HALT 

solve_constraint()', 

HALT; 

/ /  program  error 

ERROR 

print  “Found  Error” 

ERROR; 

Figure  3:  Code  that  CUTE’s  instrumentation  adds 


ai*i  +  . .  .  +  anxn+c,  where  n  >  1,  each  Xi  is  a  symbolic  vari¬ 
able,  each  Oi  is  an  integer  constant,  and  c  is  an  integer  con¬ 
stant.  Note  that  n  must  be  greater  than  0.  Otherwise,  the 
expression  is  a  constant,  and  CUTE  does  not  keep  constant 
expressions  in  .4,  because  it  keeps  A  small:  if  a  symbolic 
expression  is  constant,  its  value  can  be  obtained  from  the 
concrete  state.  The  arithmetic  constraints  are  of  the  form 
<21*1  +  . . .  +  anxn  +  c  ix  0,  where  cx  £  {<,  >,  <,  >,  =,  ^ } . 
The  pointer  expressions  are  simpler:  each  is  of  the  form  xp, 
where  xv  is  a  symbolic  variable,  or  the  constant  NULL.  The 
pointer  constraints  are  of  the  form  x  =  y  or  x  =  NULL,  where 

-  e  {=,=£}■ 

Given  any  map  A4  (e.g.,  A  or  V),  we  use  M'  =  A t[m  <— > 
w]  to  denote  the  map  that  is  the  same  as  M  except  that 
Ai'(m)  =  v.  We  use  M'  =  M  —  m  to  denote  the  map  that 
is  the  same  as  M  except  that  M' {m)  is  undefined.  We  say 
m  £domain{M)  if  M{m)  is  defined. 

Input  Initialization  using  Logical  Input  Map 

Figure  4  shows  the  procedure  initlnput{m,l )  that  uses  the 
logical  input  map  X  to  initialize  the  memory  location  m, 
to  update  the  symbolic  states  A  and  V,  and  to  update  the 
input  map  X  with  new  mappings. 

M  maps  logical  addresses  to  physical  addresses  of  mem¬ 
ory  cells  already  allocated  in  an  execution,  and  malloc{ri) 
allocates  n  fresh  cells  for  an  object  of  size  n  and  returns  the 
addresses  of  these  cells  as  a  sequence.  The  global  variable  h 
keeps  track  of  the  next  unused  logical  address  available  for 
a  newly  allocated  object. 

For  a  logical  address  l  passed  as  an  argument  to  initlnput, 
X{1)  can  be  undefined  in  two  cases:  (1)  in  the  first  execution 
when  X  is  the  empty  map,  and  (2)  when  l  is  some  logical 
address  that  got  allocated  in  the  process  of  initialization. 
If  X(l)  is  undefined  and  if  typeOf{l)  is  not  a  pointer,  then 
the  content  of  the  memory  is  initialized  randomly,  other¬ 
wise,  if  the  typeOf(l)  is  a  pointer,  then  the  contents  of  l 
and  m  are  both  initialized  to  NULL.  Note  that  CUTE  does 
not  attempt  to  generate  random  pointer  graphs  but  assigns 
all  new  pointers  to  NULL.  If  typeOf  (X(l))  is  a  pointer  to  T 
(i.e.,  T  *)  and  M{1)  is  defined,  then  we  know  that  the  ob¬ 
ject  pointed  by  the  logical  address  l  is  already  allocated  and 
we  simply  initialize  the  content  of  m  by  M(l).  Otherwise, 
we  allocate  sufficient  physical  memory  for  the  object  pointed 
by  *m  using  malloc  and  initialize  them  recursively.  In  the 


/ /  input:  m  is  the  physical  address  to  initialize 
//  Z  is  the  corresponding  logical  address 

/ /  modifies  h ,  X,  *4,  "P 
initlnput(m ,  Z) 
if  Z  0  domain  (X) 

if  (typeOf  (*m)  ==pointer  to  T)  *m  =NULL; 
else  *m  =  random ()’, 

X  =  X[Z  i— >■  *777]; 
else 

v'  =  v  =  1(1); 

if  (typeOf  (v)  ==pointer  to  T) 
if  ( v  G  domain(M)) 

*rn  —  M(v); 
else 

n  —  si;zeO/(T); 

{7711,  .  .  .  ,  771^}  =malloc(n ); 
if  (u  ==non-NULL) 

v'  =  h;  h  =  h  n;  //  h  is  the  next  logical  address 

=1=771  =  77i  1;  X  =  X[Z  1 — >  1/];  M  —  M[u  1— >  mi]; 
for  ji  —  1  to  71 

initlnput(mj  ,v'  +  j  —  1); 

else 

*771  —  v;  X  —  X[l  1 — ►  u] ; 

//  ccj  is  a  symbolic  variable  for  logical  address  Z 
if  (typeOf  (m)  =— pointer  to  T)  P  =  P[m  1— >  ; 
else  A  —  A[m  t—>  xi]; 


Figure  4:  Input  initialization 


process,  we  also  allocate  logical  addresses  by  incrementing 
h  if  necessary. 

Symbolic  Execution 

Figure  5  shows  the  pseudo-code  for  the  symbolic  manip¬ 
ulations  done  by  the  procedure  execute-symbolic  which  is 
inserted  by  CUTE  in  the  program  under  test  during  instru¬ 
mentation.  The  procedure  executesymbolic(m,  e)  evaluates 
the  expression  e  symbolically  and  maps  it  to  the  memory 
location  m  in  the  appropriate  symbolic  state. 

Recall  that  CUTE  replaces  a  symbolic  expression  that  the 
CUTE’s  constraint  solver  cannot  handle  with  the  concrete 
value  from  the  execution.  Assume,  for  instance,  that  the 
solver  can  solve  only  linear  constraints.  In  particular,  when 
a  symbolic  expression  becomes  non-linear,  as  in  the  multi¬ 
plication  of  two  non-constant  sub-expressions,  CUTE  sim¬ 
plifies  the  symbolic  expression  by  replacing  one  of  the  sub¬ 
expressions  by  its  current  concrete  value  (see  line  L  in  Fig¬ 
ure.  5).  Similarly,  if  the  statement  is  for  instance  v"  < — 

(see  line  D  in  Figure.  5),  and  both  v  and  v'  are  symbolic, 
CUTE  removes  the  memory  location  &iv”  from  both  A  and 
V  to  reflect  the  fact  that  the  symbolic  value  for  v"  is  unde¬ 
fined. 

Figure  6  shows  the  function  evaluate-predicate(p,b)  that 
symbolically  evaluates  p  and  updates  path-C.  In  case  of 
pointers,  CUTE  only  considers  predicates  of  the  form  x  =  y, 
x  y,  x  =NULL,  and  x  y^NULL,  where  x  and  y  are  symbolic 
pointer  variables.  We  discuss  this  in  Section  3.7.  If  a  sym¬ 
bolic  predicate  expression  is  constant,  then  true  or  false  is 
returned. 

At  the  time  symbolic  evaluation  of  predicates  in  the  proce¬ 
dure  evaluate-predicate,  symbolic  predicate  expressions  from 
branching  points  are  collected  in  the  array  path-C.  At  the 
end  of  the  execution,  path-c[0  . . .  i  —  1],  where  i  is  the  num¬ 
ber  of  conditional  statements  of  P  that  CUTE  executes, 
contains  all  predicates  whose  conjunction  holds  for  the  exe¬ 
cution  path. 

Note  that  in  both  the  procedures  execute-symbolic  and 


//  inputs:  m  is  a  memory  location 
//  e  is  an  expression  to  evaluate 

/ /  modifies  A  and  V  by  symbolically  executing  *m  < —  e 
executesymbolic(m ,  e) 
if  ( i  <  depth) 
match  e: 
case  “ui” : 

mi  — 

if  (ttii  G  domain (P)) 

A  —  A  —  777 ;  P  —  P\ m  i — ►  /P(t77i)];  / /  remove  if  A  contains  m 
else  if  (7711  G  domain(A)) 

A  —  A[m  i— >  A(mi)];  P  =  P  —  m; 
else  V  —  V  —  777 ;  A  —  A  —  m; 
case  “tii  ±712”:  //  where  ±  G  {+,  — } 

7771  =  Szvi ;  7772  =  SzV2  ] 

if  (7771  G  domain(A)  and  m2  G  domain(A)) 

v  =  “A(m\)  it  *4(7772)”;  //  symbolic  addition  or  subtraction 
else  if  (t?7i  G  domain(A)) 

v  =  “*4(t77i)  ±  712”;  //  symbolic  addition  or  subtraction 
else  if  (7772  G  domain(A)) 

v  =  “t;i  ±  *4(7772)”;  //  symbolic  addition  or  subtraction 
else  A  —  A  —  777;  V  —  V  —  m;  return; 

A  =  *4 [777  \—>v];'P  =  'P  —  m; 
case  “t;i  *  V2”  ’■ 

7771  —  Szvi ;  7772  =  &ZV2‘, 

if  (7771  G  domain(A)  and  m2  G  domain(A)) 

L:  v  —  “t;i  *  *4(7772)”;  //  replace  one  with  concrete  value 

else  if  (7771  G  domain(A)) 

v  =  “*4(tt7i)  *  712”;  //  symbolic  multiplication 
else  if  (7772  G  domain(A)) 

v  =  “t;i  *  *4(7772)”;  //  symbolic  multiplication 
else  A  —  A  —  777;  V  —  "P  —  777;  return; 

A  —  A[m  1— ►  7;] ;  V  —  V  —  m; 
case  “*ui”: 

7772  =  ^1 ; 

if  (7772  £  domain ('P))  A  —  A  —  m;  'P  —  P[m  1— ►  7^(7772)]; 
else  if  (7772  G  domain(A))  A  —  .4 [777  1— »  *4(7772)];  V  —  P  —  m; 
else  A  =  A  —  m;P  —  P  —  m; 

default: 

D:  A  —  A  —  777;  P  =  P  —  777; 

Figure  5:  Symbolic  execution 


evaluate-predicate,  we  skip  symbolic  execution  if  the  number 
of  predicates  executed  so  far  (recorded  in  the  global  variable 
i)  becomes  greater  than  the  parameter  depth,  which  gives 
the  depth  of  bounded  DFS  described  next. 

Bounded  Depth-First  Search 

To  explore  paths  in  the  execution  tree,  CUTE  implements 
a  (bounded)  depth-first  strategy  (bounded  DFS).  In  the 
bounded  DFS,  each  run  (except  the  first)  is  executed  with 
the  help  of  a  record  of  the  conditional  statements  (which  is 
the  array  branch-hist)  executed  in  the  previous  run.  The 
procedure  cmp-nset-branchJiist  in  figure  7  checks  whether 
the  current  execution  path  matches  the  one  predicted  at  the 
end  of  the  previous  execution  and  represented  in  the  variable 
branch-hist.  We  observed  in  our  experiments  that  the  exe¬ 
cution  almost  always  follows  a  prediction  of  the  outcome  of 
a  conditional.  However,  it  could  happen  that  a  prediction  is 
not  fulfilled  because  CUTE  approximates,  when  necessary, 
symbolic  expressions  with  concrete  values  (as  explained  in 
Section  3.4),  and  the  constraint  solver  could  then  produce 
a  solution  that  changes  the  outcome  of  some  earlier  branch. 
(Note  that  even  when  there  is  an  approximation,  the  so¬ 
lution  does  not  necessary  change  the  outcome.)  If  it  ever 
happens  that  a  prediction  is  not  fulfilled,  an  exception  is 
raised  to  restart  run-CUTE  with  a  fresh  random  input. 

Bounded  depth-first  search  proves  useful  when  the  length 
of  execution  paths  are  infinite  or  long  enough  to  prevent  ex¬ 
haustively  search  the  whole  computation  tree.  Particularly, 


/ /  inputs:  p  is  a  predicate  to  evaluate 
//  b  is  the  concrete  value  of  the  predicate  in  <S 

/ /  modifies  path-C ,  i 
evaluat  e-predicat  e(p ,  6) 
if  (i  <  depth) 
match  p: 

case  “u i  M  U2 ” :  //  where  X!  £  {<,<•>:>  ?  >  } 
mi  =  ;  m2  —  &u2 ; 

if  (mi  £  domain(A)  and  m2  £  domain(A)) 
c  —  M(mi)  —  ^4(m2)  txi  0”; 
else  if  (mi  £  domain(A)) 
c  =  “v4(mi)  —  u2  tx  0” ; 
else  if  (m2  £  domain(A)) 
c  —  “v±  —  A(m2)  tx  0” ; 
else  c  =  b; 

case  “ui  :=  u2”:  //  where  ^  £  {=,7^} 
mi  —  &ui ;  m2  —  &u2 ; 

if  (mi  £  domain( V)  and  m2  £  domain ('P)) 
c  =  “V(m i)  ^  7 :>(m2)”; 
else  if  (mi  £  domain( V)  and  u2  ==NULL) 
c  =  “?(mi)  ^  NULL”; 

else  if  (m2  £  domain(V)  and  v\  =— NULL) 
c  =  uV(m2)  =  NULL”; 

else  if  (mi  £  domain(A)  and  m2  £  domain(A)) 
c  =  “v4(mi)  —  A(m2)  —  0”; 
else  if  (mi  £  domain(A))  c  =  iiA(m\)  —  i>2  —  0”; 
else  if  (m2  £  domain(A))  c  =  “i>i  —  A(m2)  ^  0”; 
else  c  =  b; 
if  (b)  path-c[i]  —  c; 
else  path-c[i\  =neg(c); 
cmp  -nset-branch-hist(b); 
i  =  i  +  1; 

Figure  6:  Symbolic  evaluation  of  predicates 

/ /  modifies  branch-hist 
cmp  -nset-branch-hist  (branch) 
if  ( i  <  |  branch-hist  | ) 

if  ( branch-hist  [i] .  branch^  branch) 
print  “Prediction  Failed” ; 
raise  an  exception;  //  restart  run-CUTE 
else  if  ( i  ==  |  branch-hist  \  —  1) 
branch-hist[i\.done  =true; 
else  branch-hist[i\. branch  —  branch; 
branch  _hist[i\.  done  =  false; 

Figure  7:  Prediction  checking 


it  is  important  for  generating  finite  sized  data  structures 
when  using  preconditions  such  as  data  structure  invariants 
(see  section  3.6.  For  example,  if  we  use  an  invariant  to 
generate  sorted  binary  trees,  then  a  non-bounded  depth- 
first  search  would  end  up  generating  infinite  number  of  trees 
whose  every  node  has  at  most  one  left  children  and  no  right 
children. 

3.5  Constraint  Solving 

We  next  present  how  CUTE  solves  path  constraints. 
Given  a  path  constraint  C=negJast(path-c[0 . .  .j]),  CUTE 
checks  if  C  is  satisfiable,  and  if  so,  finds  a  satisfying  solution 
I'. 

We  have  implemented  a  constraint  solver  for  CUTE  to  op¬ 
timize  solving  of  the  path  constraints  that  arise  in  concolic 
execution.  Our  solver  is  built  on  top  of  lp_solve  [18],  a  con¬ 
straint  solver  for  linear  arithmetic  constraints.  Our  solver 
provides  three  important  optimizations  for  path  constraints: 
(OPT  1)  Fast  unsatisfiability  check:  The  solver  checks 
if  the  last  constraint  is  syntactically  the  negation  of  any 
preceding  constraint;  if  it  is,  the  solver  does  not  need  to 
invoke  the  expensive  semantic  check.  (Experimental  results 
show  that  this  optimization  reduces  the  number  of  semantic 
checks  by  60-95%.) 


/ /  modifies  branch-hist,  X,  completed 
solve_constraint( )  = 

j  =  i  —  i; 

while  ( j  >  0) 

if  (branch-hist [j] . done  ==  false) 

branch-hist  [ j ] .  branch=  —>  branch-hist  [j] .  branch; 
if  (3X'  that  satisfies  neg-last(path-c[ 0.  .  •  j])) 
branch-hist=  branch-hist [ 0  .  .  .  j]; 

1  =  1'; 
return; 
else  j  =  j  —  1; 
else  j  =  j  —  1; 
if  (j  <  0)  completed= true; 

Figure  8:  Constraint  solving 


(OPT  2)  Common  sub-constraints  elimination:  The 

solver  identifies  and  eliminates  common  arithmetic  sub¬ 
constraints  before  passing  them  to  the  lp_solve.  (This  sim¬ 
ple  optimization,  along  with  the  next  one,  is  significant  in 
practice  as  it  can  reduce  the  number  of  sub-constraints  by 
64%  to  90%. ) 

(OPT  3)  Incremental  solving:  The  solver  identifies  de¬ 
pendency  between  sub-constraints  and  exploits  it  to  solve 
the  constraints  faster  and  keep  the  solutions  similar.  We 
explain  this  optimization  in  detail. 

Given  a  predicate  p  in  C,  we  define  vars(p)  to  be  the  set  of 
all  symbolic  variables  that  appear  in  p.  Given  two  predicates 
p  and  p'  in  C,  we  say  that  p  and  p'  are  dependent  if  one  of 
the  following  conditions  holds: 

1.  vars(p)  fl  vars(p')  7  0,  or 

2.  there  exists  a  predicate  p"  in  C  such  that  p  and  p"  are 
dependent  and  p'  and  p"  are  dependent. 

Two  predicates  are  independent  if  they  are  not  dependent. 

The  following  is  an  important  observation  about  the  path 
constraints  C  and  C'  from  two  consecutive  concolic  execu¬ 
tions:  C  and  C'  differ  in  the  small  number  of  predicates 
(more  precisely,  only  in  the  last  predicate  when  there  is  no 
backtracking),  and  thus  their  respective  solutions  X  and  X' 
must  agree  on  many  mappings.  Our  solver  exploits  this  ob¬ 
servation  to  provide  more  efficient,  incremental  constraint 
solving.  The  solver  collects  all  the  predicates  in  C  that 
are  dependent  on  -ipath-c[j}.  Let  this  set  of  predicates  be 
D.  Note  that  all  predicates  in  D  are  either  linear  arith¬ 
metic  predicates  or  pointer  predicates,  because  no  predicate 
in  C  contains  both  arithmetic  symbolic  variables  and  pointer 
symbolic  variables.  The  solver  then  finds  a  solution  X"  for 
the  conjunction  of  all  predicates  from  D.  The  input  for  the 
next  run  is  then  X'  =  X[X"]  which  is  the  same  as  X  except 
that  for  every  l  for  which  X"(l)  is  defined,  X'(l)  =  X"(l).  In 
practice,  we  have  found  that  the  size  of  D  is  almost  one- 
eighth  the  size  of  C  on  average. 

If  all  predicates  in  D  are  linear  arithmetic  predicates,  then 
CUTE  uses  integer  linear  programming  to  compute  X" .  If 
all  predicates  in  D  are  pointer  predicates,  then  CUTE  uses 
the  following  procedure  to  compute  X" . 

Let  us  consider  only  pointer  constraints,  which  are  either 
equalities  or  disequalities.  The  solver  first  builds  an  equiv¬ 
alence  graph  based  on  (dis)equalities  (similar  to  checking 
satisfiability  in  theory  of  equality  [2])  and  then  based  on 
this  graph,  assigns  values  to  pointers.  The  values  assigned 
to  the  pointers  can  be  a  logical  address  in  the  domain  of 
X ,  the  constant  non-NULL  (a  special  constant),  or  the  con¬ 
stant  NULL  (represented  by  0).  The  solver  views  NULL  as  a 


/ /  inputs:  p  is  a  symbolic  pointer  predicate 
//  X  is  the  previous  solution 

/ /  returns:  a  new  solution  X" 
soLve-pointer (p ,  X) 

match  p: 

case  “x  t^NULL”  :  X/r  =  { //  non-NULL  y  £  [x]  =  }; 
case  “x  —NULL”:  X"  —  { y  e-»NULL|  y  £  [x]=}; 
case  “x  —  y” :  X;/  -{2  — •  v  \  2  £  [y]  =  and  X(x)  —  u}; 
case  “x  ^  y” :  X;/  —  {2  i— >  non-NULL  2  £  [y]  =  } ; 
return  X" ; 

Figure  9:  Assigning  values  to  pointers 


symbolic  variable.  Thus,  all  predicates  in  D  are  of  the  form 
x  =  y  or  x  ^  y,  where  x  and  y  are  symbolic,  variables.  Let 
D'  be  the  subset  of  D  that  does  not  contain  the  predicate 
-1  path-c[j].  The  solver  first  checks  if  -> path-c[j ]  is  consistent 
with  the  predicates  in  D.  For  this,  the  solver  constructs  an 
undirected  graph  whose  nodes  are  the  equivalence  classes 
(with  respect  to  the  relation  =)  of  all  symbolic  variables 
that  appear  in  D' .  We  use  [x]=  to  denote  the  equivalence 
class  of  the  symbolic  variable  x.  Given  two  nodes  denoted 
by  the  equivalence  classes  [x]=  and  [y]=,  the  solver  adds  an 
edge  between  [x]=  and  [y]  =  iff  there  exists  symbolic  vari¬ 
ables  u  and  v  such  that  u  ^  v  exists  in  D1  and  u  £  [x]=  and 
v  £  [y]  =  -  Given  the  graph,  the  solver  finds  that  -1  path-c[j] 
is  satisfiable  if  -ipath-c[j]  is  of  the  form  x  =  y  and  there  is 
no  edge  between  [x]=  and  [y]=  in  the  graph;  otherwise,  if 
^path-c[j]  is  of  the  form  x  y,  then  -ipath-c[j]  is  satisfi¬ 
able  if  [*]  =  and  [y\=  are  not  the  same  equivalence  class.  If 
-1 path-c[j ]  is  satisfiable,  the  solver  computes  T"  using  the 
procedure  solve-pointer(^path-c[j],  I)  shown  in  Figure  9. 

Note  that  after  solving  the  pointer  constraints,  we  either 
add  (by  assigning  a  pointer  to  non-NULL)  or  remove  a  node 
(by  assigning  a  pointer  NULL)  from  the  current  input  graph, 
or  alias  or  non-alias  two  existing  pointers.  This  keeps  the 
consecutive  solutions  similar.  Keeping  consecutive  solutions 
for  pointers  similar  is  important  because  of  the  logical  input 
map:  if  inputs  were  very  different,  CUTE  would  need  to 
rebuild  parts  of  the  logical  input  map. 

3.6  Data  Structure  Testing 

We  next  consider  testing  of  functions  that  take  data  struc¬ 
tures  as  inputs.  More  precisely,  a  function  has  some  pointer 
arguments,  and  the  memory  graph  reachable  from  the  point¬ 
ers  forms  a  data  structure.  For  instance,  consider  testing  of 
a  function  that  takes  a  list  and  removes  an  element  from  it. 
We  cannot  simply  test  such  function  in  isolation  [5,27,30]  — 
say  generating  random  memory  graphs  as  inputs — because 
the  function  requires  the  input  memory  graph  to  satisfy  the 
data  structure  invariant.1  If  an  input  is  invalid  (i.e.,  vi¬ 
olates  the  invariant),  the  function  provides  no  guarantees 
and  may  even  result  in  an  error.  For  instance,  a  function 
that  expects  an  acyclic  list  may  loop  infinitely  given  a  cyclic 
list,  whereas  a  function  that  expects  a  cyclic  list  may  deref¬ 
erence  NULL  given  an  acyclic  list.  We  want  to  test  such 
functions  with  valid  inputs  only.  There  are  two  main  ap¬ 
proaches  to  obtaining  valid  inputs:  (1)  generating  inputs 
with  call  sequences  [27,  30]  and  (2)  solving  data  structure 
invariants  [5,27].  CUTE  supports  both  approaches. 


1The  functions  may  have  additional  preconditions,  but  we 
omit  them  for  brevity  of  discussion;  for  more  details,  see  [5] . 


Generating  Inputs  with  Call  Sequences: 

One  approach  to  generating  data  structures  is  to  use  se¬ 
quences  of  function  calls.  Each  data  structure  implements 
functions  for  several  basic  operations  such  as  creating  an 
empty  structure,  adding  an  element  to  the  structure,  re¬ 
moving  an  element  from  the  structure,  and  checking  if  an 
element  is  in  the  structure.  A  sequence  of  these  operations 
can  be  used  to  generate  an  instance  of  data  structure,  e.g., 
we  can  create  an  empty  list  and  add  several  elements  to  it. 
This  approach  has  two  requirements  [27]:  (1)  all  functions 
must  be  available  (and  thus  we  cannot  test  each  function  in 
isolation),  and  (2)  all  functions  must  be  used  in  generation: 
for  complex  data  structures,  e.g.,  red-black  trees,  there  are 
memory  graphs  that  cannot  be  constructed  through  addi¬ 
tions  only  but  require  removals  [27, 30] . 

Solving  Data  Structure  Invariants: 

Another  approach  to  generating  data  structures  is  to  use  the 
functions  that  check  invariants.  Good  programming  prac¬ 
tice  suggests  that  data  structures  provide  such  functions. 
For  example,  SGLIB  [25]  (see  Section  5.2)  is  a  popular  C 
library  for  generic  data  structures  that  provides  such  func¬ 
tions.  We  call  these  functions  repOk  [5].  (SGLIB  calls  them 
check_consistency.)  As  an  illustration,  SGLIB  implements 
operations  on  doubly  linked  lists  and  provides  a  repOk  func¬ 
tion  that  checks  if  a  memory  graph  is  a  valid  doubly  linked 
list;  each  repOk  function  returns  true  or  false  to  indicate 
the  validity  of  the  input  graph. 

The  main  idea  of  using  repOk  functions  for  testing  is  to 
solve  repOk  functions,  i.e.,  generate  only  the  input  mem¬ 
ory  graphs  for  which  repOk  returns  true  [5,27].  This  ap¬ 
proach  allows  modular  testing  of  functions  that  implement 
data  structure  operations  (i.e.,  does  not  require  that  all  op¬ 
erations  be  available):  all  we  need  for  a  function  under  test 
is  a  corresponding  repOk  function.  Previous  techniques  for 
solving  repOk  functions  include  a  search  that  uses  purely 
concrete  execution  [5]  and  a  search  that  uses  symbolic  execu¬ 
tion  for  primitive  data  but  concrete  values  for  pointers  [27]. 
CUTE,  in  contrast,  uses  symbolic  execution  for  both  prim¬ 
itive  data  and  pointers. 

The  constraints  that  CUTE  builds  and  solves  for  pointers 
allow  it  to  solve  repOk  functions  asymptotically  faster  than 
the  fastest  previous  techniques  [5,27].  Consider,  for  exam¬ 
ple,  the  following  check  from  the  invariant  for  doubly  linked 
list:  for  each  node  n,  n.next.prev  ==  n.  Assume  that  the 
solver  is  building  a  doubly  linked  list  with  N  nodes  reachable 
along  the  next  pointers.  Assume  also  that  the  solver  needs 
to  set  the  values  for  the  prev  pointers.  Executing  the  check 
once,  CUTE  finds  the  exact  value  for  each  prev  pointer  and 
thus  takes  O(N)  steps  to  find  the  values  for  all  N  prev  point¬ 
ers.  In  contrast,  the  previous  techniques  [5,27]  take  0(N2) 
steps  as  they  search  for  the  value  for  each  pointer,  trying 
first  the  value  NULL,  then  a  pointer  to  the  head  of  the  list, 
then  a  pointer  to  the  second  element  and  so  on. 

3.7  Approximations  for  Scalable 
Symbolic  Execution 

CUTE  uses  simple  symbolic  expressions  for  pointers  and 
builds  only  (dis)equality  constraints  for  pointers.  We  be¬ 
lieve  that  these  constraints,  which  approximate  the  exact 
path  condition,  are  a  good  trade-off.  To  exactly  track  the 
pointer  constraints,  it  would  be  necessary  to  use  the  theory 
of  arrays/memory  with  updates  and  selections  [19].  How- 


ever,  it  would  make  the  symbolic  execution  more  expensive 
and  could  result  in  constraints  whose  solution  is  intractable. 
Therefore,  CUTE  does  not  use  the  theory  of  arrays  but 
handles  arrays  by  concretely  instantiating  them  and  mak¬ 
ing  each  element  of  the  array  a  scalar  symbolic  variable. 

It  is  important  to  note  that,  although  CUTE  uses  sim¬ 
ple  pointer  constraints,  it  still  keeps  a  precise  relationship 
between  pointers:  the  logical  input  map  (through  types), 
maintains  a  relationship  between  pointers  to  structs  and 
their  fields  and  between  pointers  to  arrays  and  their  ele¬ 
ments.  For  example,  from  the  logical  input  map  (3, 1,3,0) 
for  Input  3  from  Figure  1,  CUTE  knows  that  p->next  is 
at  the  (logical)  address  4  because  p  has  value  3,  and  the 
field  next  is  at  the  offset  1  in  the  struct  cell.  Indeed,  the 
logical  input  map  allows  CUTE  to  use  only  simple  scalar 
symbolic  variables  to  represent  the  memory  and  still  obtain 
fairly  precise  constraints. 

Finally,  we  show  that  CUTE  does  not  keep  the  exact 
pointer  constraints.  Consider  for  example  the  code  snippet 
*p=0;  *q=l;  if  (*p  ==  1)  ERROR  (and  assume  that  p  and 
q  are  not  NULL).  CUTE  cannot  generate  the  constraint  p==q 
that  would  enable  the  program  to  take  the  “then”  branch. 
This  is  because  the  program  contains  no  conditional  that 
can  generate  the  constraint.  Analogously,  for  the  code  snip¬ 
pet  a[i]=0;  a[j]=l;  if  (a[i]==0)  ERROR,  CUTE  cannot 
generate  i==j  • 

4.  IMPLEMENTATION 

We  have  implemented  the  main  parts  of  CUTE  in  C,  fol¬ 
lowing  the  algorithms  from  the  previous  section.  To  instru¬ 
ment  programs  under  test  to  simultaneously  run  both  con¬ 
crete  and  symbolic  executions,  we  use  CIL  [20],  an  OCAML 
application  for  parsing  and  transforming  C  programs.  To 
solve  arithmetic  inequalities,  the  constraint  solver  of  CUTE 
uses  lp_solve  [18],  a  library  for  integer  programming. 

4.1  Program  Instrumentation: 

To  instrument  the  code,  CUTE  first  uses  CIL  to  simplify 
a  C  program  into  the  three-address  code  that  closely  fol¬ 
lows  the  syntax  given  in  Figure  2.  The  difference  is  that 
an  expression  e  can  also  be  a  function  call  of  the  form 
furi-name(v i,...,vn).  After  the  simplification,  CUTE  in¬ 
serts  instrumentation  code  throughout  the  simplified  code 
for  concolic  execution  at  runtime. 

Figure  10  shows  examples  of  the  code  that  CUTE  adds 
during  instrumentation  for  function  calls  and  function  def¬ 
inition.  The  procedure  push(&cv)  pushes  the  symbolic  ex¬ 
pression  for  the  address  &iv  to  a  symbolic  stack  used  for 
passing  symbolic  arguments  during  function  calls.  The  re¬ 
verse  procedure  pop(&zv)  pops  a  symbolic  expression  from 
the  symbolic  stack  and  assigns  it  to  the  address  &iv. 

A  difference  between  CUTE  and  traditional  symbolic  exe¬ 
cution  is  that  CUTE  does  not  require  instrumentatin  of  the 
whole  program.  Calls  to  uninstrumented  functions  proceed 
only  with  the  concrete  execution,  without  symoblic  execu¬ 
tion.  This  allows  CUTE  to  handle  programs  that  use  binary 
libraries  whose  source  code  is  not  available. 

4.2  CUTE  Toolkit: 

The  CUTE  toolkit  provides  two  commands,  cutec  and 
cute,  for  code  instrumentation  and  running  of  the  instru¬ 
mented  code.  The  toolkit  also  provides  four  macros  that 
give  the  user  additional  control  over  the  instrumentation. 


Before  Instrumentation 

After  Instrumentation 

/ /  function  call 

V  = 

push(Ozvi);  . . . ;  push(&v„); 
v  =  f(vi, . . . ,  vn); 
pop(&zv); 

/ /  function  def 
Tf(T\Xl,.  .  .  ,  TnXn)  { 

B-  //  body 
return  v;  } 

Tf(T!  XU...,Tn  Xn)  { 
pop(hx l);  . . . ;  pop(&zxn); 
B; 

push(&cv)', 

return  v;  } 

Figure  10:  Code  that  CUTE’s  instrumentation  adds 
for  function  calls  and  function  definitions. 

The  command  cutec  expects  a  set  of  C  files  and  a  toplevel 
function;  cutec  instruments  the  C  files  and  compiles  the  in¬ 
strumented  files  with  a  C  compiler,  cutec  assumes  that  the 
program  starts  by  calling  the  toplevel  function  and  that  the 
input  to  the  program  consists  of  the  memory  graph  reach¬ 
able  from  the  arguments  passed  to  the  toplevel  function, 
cutec  generates  a  main  function  that  first  initializes  the  in¬ 
put  for  the  toplevel  function  and  the  symbolic  state,  and 
then  calls  the  instrumented  toplevel  function  with  the  gen¬ 
erated  input.  At  the  end  of  the  execution  of  the  toplevel 
function,  main  calls  the  constraint  solver  to  generate  input 
for  the  next  execution  and  stores  the  inputs  in  a  file. 

The  command  cute  takes  the  executable  generated  by 
cutec  and  executes  it  iteratively  until  an  error  is  found  or 
full  branch  coverage  is  attained  or  a  depth-first  search  com¬ 
pletes.  If  an  error  is  found,  cute  invokes  a  debugger  for  the 
user  to  replay  the  erroneous  execution. 

The  CUTE  library  provides  the  following  macros  that  the 
user  can  insert  into  the  C  code  under  test: 

1)  CUTE_input  (x) ,  allows  user  to  specify  that  the  variable  x 

(of  any  type,  including  a  pointer)  is  an  input,  in  addition  to 
the  arguments  of  the  toplevel  function.  This  comes  handy 
to  replace  any  external  user  input,  e.g.,  scanf (‘  ’  ,&v) 

by  CUTE_input  (v)  (which  also  assigns  value  to  &v). 

2)  CUTE_input_array (p ,  size) .  This  macro  is  similar  to 
CUTE_input  except  that  it  assumes  that  p  is  a  pointer  and 
specifies  that  p  points  to  an  array  of  size  size. 

3)  CUTE_assume  (pred) ,  where  pred  is  some  C  predicate. 
This  macro  allows  the  execution  to  proceed  if  the  pred  holds. 
This  way  we  can  restrict  the  input,  e.g.,  the  predicate  can 
be  a  repOkO  call  for  some  data  structure. 

4)  CUTE_assert  (pred) .  This  macro  specifies  an  assertion 
whose  violation  is  considered  an  error. 

5.  EXPERIMENTAL  EVALUATION 

We  illustrate  two  case  studies  that  show  how  CUTE  can 
detect  errors.  In  the  second  case  study,  we  also  present 
results  that  show  how  CUTE  achieves  branch  coverage  of 
the  code  under  test.  We  performed  all  experiments  on  a 
Linux  machine  with  a  dual  1.7  GHz  Intel  Xeon  processor. 

5.1  Data  Structures  of  CUTE 

We  applied  CUTE  to  test  its  own  data  structures.  CUTE 
uses  a  number  of  non-standard  data  structures  at  run¬ 
time,  such  as  cu_linear  to  represent  linear  expressions, 
cu_pointer  to  represent  pointer  expressions,  cu_depend  to 
represent  dependency  graphs  for  path  constraints  etc.  Our 
goal  in  this  case  study  was  to  detect  memory  leaks  in  addi¬ 
tion  to  standard  errors  such  as  segmentation  faults,  assertion 
violation  etc.  To  that  end,  we  used  CUTE  in  conjunction 


with  valgrind  [26].  We  discovered  a  few  memory  leaks  and 
a  couple  of  segmentation  faults  that  did  not  show  up  in 
other  uses  of  CUTE.  This  case  study  is  interesting  in  that 
we  applied  CUTE  to  partly  unit  test  itself  and  discovered 
bugs.  We  briefly  describe  our  experience  with  testing  the 
cu_linear  data  structure. 

We  tested  the  cu_linear  module  of  CUTE  in  the  depth- 
first  search  mode  of  CUTE  along  with  valgrind.  In  537  it¬ 
erations,  CUTE  found  a  memory  leak.  The  following  is  a 
snippet  of  the  function  cu_linear_add  relevant  for  the  mem¬ 
ory  leak: 


cu_linear  * 

cu_linear_add(cu_linear  *cl,  cu_linear  *c2,  int  add)  { 

int  i,  j; 

cu_linear*  ret=(cu_linear*)malloc(sizeof (cu_linear)) ; 

...  //  skipped  18  lines  of  code 

if (ret->count==0)  return  NULL; 

If  the  sum  of  the  two  linear  expressions  passed  as  arguments 
becomes  constant,  the  function  returns  NULL  without  freeing 
the  memory  allocated  for  the  local  variable  ret.  CUTE  con¬ 
structed  this  scenario  automatically  at  the  time  of  testing. 
Specifically,  CUTE  constructed  the  sequence  of  function 
calls  ll=cu_linear .create (0)  ;  ll=cu_linear .create (0)  ; 
ll=cu_linear jnegate (11) ;  ll=cu_linear_add(ll ,12,1); 
that  exposes  the  memory  leak  that  valgrind  detects. 

5.2  SGLIB  Library 

We  also  applied  CUTE  to  unit  test  SGLIB  [25]  version 
1.0.1,  a  popular,  open-source  C  library  for  generic  data 
structures.  The  library  has  been  extensively  used  to  im¬ 
plement  the  commercial  tool  Xrefactory.  SGLIB  consists  of 
a  single  C  header  hie,  sglib.h,  with  about  2000  lines  of  code 
consisting  only  of  C  macros.  This  Hie  provides  generic  im¬ 
plementation  of  most  common  algorithms  for  arrays,  lists, 
sorted  lists,  doubly  linked  lists,  hash  tables,  and  red-black 
trees.  Using  the  SGLIB  macros,  a  user  can  declare  and 
define  various  operations  on  data  structures  of  parametric 
types. 

The  library  and  its  sample  examples  provide  verifier  func¬ 
tions  (can  be  used  as  repOk)  for  each  data  structure  ex¬ 
cept  for  hash  tables.  We  used  these  verifier  functions  to 
test  the  library  using  the  technique  of  repOk  mentioned  in 
Section  3.6.  For  hash  tables,  we  invoked  a  sequence  of  its 
function.  We  used  CUTE  with  bounded  depth-first  search 
strategy  with  bound  50.  Figure  11  shows  the  results  of  our 
experiments. 

We  chose  SGLIB  as  a  case  study  primarily  to  measure  the 
efficiency  of  CUTE.  As  SGLIB  is  widely  used,  we  did  not 
expect  to  find  bugs.  Much  to  our  surprise,  we  found  two 
bugs  in  SGLIB  using  CUTE. 

The  first  bug  is  a  segmentation  fault  that  occurs  in  the 
doubly-linked-list.  library  when  a  non-zero  length  list  is  con¬ 
catenated  with  another  zero-length  list.  CUTE  discovered 
the  bug  in  140  iterations  (about  1  seconds)  in  the  bounded 
depth-first  search  mode.  This  bug  is  easy  to  Hx  by  putting 
a  check  on  the  length  of  the  second  list  in  the  concatenation 
function. 

The  second  bug,  which  is  a  more  serious  one,  was  found 
by  CUTE  in  the  hash  table  library  in  193  iterations  (in  1 
second).  Specifically,  CUTE  constructed  the  following  valid 
sequence  of  function  calls  which  gets  the  library  into  an  in¬ 
finite  loop: 


typedef  struct  ilist  {  int  i;  struct  ilist  *next;  }  ilist; 
ilist  *htab[10]  ; 
mainO  { 

struct  ilist  *e,*el,*e2,*m; 

sglib_hashed_ilist_init (htab) ; 

e=(ilist  *)malloc(sizeof (ilist)) ;  e->next  =  0;  e->i=0; 

sglib_hashed_ilist_add_if _not_member (htab,e ,&m) ; 

sglib_hashed_ilist_add(htab,e) ; 

e2=(ilist  *)malloc(sizeof (ilist)) ;  e2->next  =  0;  e2->i=0; 

sglib_hashed_ilist_is_member (htab,e2) ;  } 

where  ilist  is  a  struct  representing  an  element  of  the  hash 
table.  We  reported  these  bugs  to  the  SGLIB  developers,  who 
confirmed  that  these  are  indeed  bugs. 

Figure  11  shows  the  results  for  testing  SGLIB  1.0.1  with 
the  bounded  depth-first  strategy.  For  each  data  structure 
and  array  sorting  algorithm  that  SGLIB  implements,  we 
tabulate  the  time  that  CUTE  took  to  test  the  data  struc¬ 
ture,  the  number  of  runs  that  CUTE  made,  the  number  of 
branches  it  executed,  branch  coverage  obtained,  the  number 
of  functions  executed,  the  benefit  of  optimizations,  and  the 
number  of  bugs  found. 

The  branch  coverage  in  most  cases  is  less  than  100%.  Af¬ 
ter  investigating  the  reason  for  this,  we  found  that  the  code 
contains  a  number  of  assert  statements  that  were  never  vi¬ 
olated  and  a  number  of  predicates  that  are  redundant  and 
can  be  removed  from  the  conditionals. 

The  last  two  columns  in  Figure  11  show  the  benefit  of  the 
three  optimizations  from  Section  3.5.  The  column  OPT  1 
gives  the  average  percentage  of  executions  in  which  the  fast 
unsatisfiability  check  was  successful.  It  is  important  to  note 
that  the  saving  in  the  number  of  satisfiability  checks  trans¬ 
lates  into  an  even  higher  relative  saving  in  the  satishability- 
checking  time  because  lp_solve  takes  much  more  time  (ex¬ 
ponential  in  number  of  constraints)  to  determine  that  a  set 
of  constraints  is  unsatishable  than  to  generate  a  solution 
when  one  exists.  For  example,  for  red-black  trees  and  depth- 
first  search,  OPT  1  was  successful  in  almost  90%  of  execu¬ 
tions,  which  means  that  OPT  1  reduces  the  number  of  calls 
to  lp_solve  an  order  of  magnitude.  However,  OPT  1  re¬ 
duces  the  solving  time  of  lp_solve  more  than  two  orders  of 
magnitude  in  this  case;  in  other  words,  it  would  be  infeasible 
to  run  CUTE  without  OPT  1.  The  column  OPT  2  &  3  gives 
the  average  percentage  of  constraints  that  CUTE  eliminated 
in  each  execution  due  to  common  sub-expression  elimination 
and  incremental  solving  optimizations.  Yet  again,  this  re¬ 
duction  in  the  size  of  constraint  set  translates  into  a  much 
higher  relative  reduction  in  the  solving  time. 

6.  RELATED  WORK 

Automating  unit  testing  is  an  active  area  of  research.  In 
the  last  five  years,  over  a  dozen  of  techniques  and  tools  have 
been  proposed  that  automatically  increase  test  coverage  or 
generate  test  inputs. 

The  simplest,  and  yet  often  very  effective,  techniques  use 
random  generation  of  (concrete)  test  inputs  [4,8,10,21,22]. 
Some  recent  tools  use  bounded-exhaustive  concrete  execu¬ 
tion  [5,  12,  29]  that  tries  all  values  from  user-provided  do¬ 
mains.  These  tools  can  achieve  high  code  coverage,  espe¬ 
cially  for  testing  data  structure  implementation.  However, 
they  require  the  user  to  carefully  choose  the  values  in  the 
domains  to  ensure  high  coverage. 

Tools  based  on  symbolic  execution  use  a  variety  of  ap¬ 
proaches — including  abstraction-based  model  checking  [1,3], 
explicit-state  model  checking  [27],  symbolic-sequence  explo- 
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Figure  11:  Results  for  testing  SGLIB  1.0.1  with  bounded  depth-first  strategy  with  depth  50 


ration  [23,30],  and  static  analysis  [9] — to  detect  (potential) 
bugs  or  generate  test  inputs.  These  tools  inherit  the  incom¬ 
pleteness  of  their  underlying  reasoning  engines  such  as  theo¬ 
rem  provers  and  constraint  solvers.  For  example,  tools  using 
precise  symbolic  execution  [27, 30]  cannot  analyze  any  code 
that  would  build  constraints  out  of  pre-specified  theories, 
e.g.,  any  code  with  non-linear  arithmetic  or  array  indexing 
with  non-constant  expressions.  As  another  example,  tools 
based  on  predicate  abstraction  [1,3]  do  not  handle  code  that 
depends  on  complex  data  structures.  In  these  tools,  the 
symbolic  execution  proceeds  separately  from  the  concrete 
execution  (or  constraint  solving). 

The  closest  work  to  ours  is  that  of  Godefroid  et  al.’s  di¬ 
rected  automated  random  testing  (DART)  [11].  DART  con¬ 
sists  of  three  parts:  (1)  directed  generation  of  test  inputs, 
(2)  automated  extraction  of  unit  interfaces  from  source  code, 
and  (3)  random  generation  of  test  inputs.  CUTE  does  not 
provide  automated  extraction  of  interfaces  but  leaves  it  up 
to  the  user  to  specify  which  functions  are  related  and  what 
their  preconditions  are.  Unlike  DART  that  was  applied 
to  testing  each  function  in  isolation  and  without  precon¬ 
ditions,  CUTE  targets  related  functions  with  preconditions 
such  as  data  structure  implementations.  DART  handles  con¬ 
straints  only  on  integer  types  and  cannot  handle  programs 
with  pointers  and  data  structures;  in  such  situations,  DART 
tool’s  testing  reduces  to  simple  and  ineffective  random  test¬ 
ing.  DART  proposed  a  simple  strategy  to  generate  random 
memory  graphs:  each  pointer  is  either  NULL  or  points  to 
a  new  memory  cell  whose  nodes  are  recursively  initialized. 
This  strategy  suffers  from  several  deficiencies: 

1.  The  random  generation  itself  may  not  terminate  [7]. 

2.  The  random  generation  produces  only  trees;  there  is  no 
sharing  and  aliasing,  so  there  are  no  DAGs  or  cycles. 

3.  The  directed  generation  does  not  keep  track  of  any 
constraints  on  pointers. 

4.  The  directed  generation  never  changes  the  underlying 
memory  graph;  it  can  only  change  the  (primitive,  in¬ 
teger)  values  in  the  nodes  in  the  graph. 

DART  also  does  not  consider  any  preconditions  for  the  code 
under  test.  For  example,  in  the  oSIP  case  study  [11],  it  is 
unclear  whether  some  NULL  values  are  actual  bugs  or  false 
alarms  due  to  violated  preconditions.  Moreover,  CUTE  im¬ 
plements  a  novel  constraint  solver  that  significantly  speeds 
up  the  analysis. 

Cadar  and  Engler  proposed  Execution  Generated  Test¬ 
ing  (EGT)  [6]  that  takes  a  similar  approach  to  testing  as 
CUTE:  it  explores  different  execution  paths  using  a  com¬ 
bined  symbolic  and  concrete  execution.  However,  EGT  did 
not  consider  inputs  that  are  memory  graphs  or  code  that  has 
preconditions.  Also,  EGT  and  CUTE  differ  in  how  they  ap¬ 
proximate  symbolic  expressions  with  concrete  values.  EGT 


follows  a  more  traditional  approach  to  symbolic  execution 
and  proposes  an  interesting  method  that  lazily  solves  the 
path  constraints:  EGT  starts  with  only  symbolic  inputs  and 
tries  to  execute  the  code  fully  symbolically,  but  if  it  cannot, 
EGT  solves  the  current  constraints  to  generate  a  (partial) 
concrete  input  with  which  the  execution  proceeds. 

CUTE  is  also  related  to  the  prior  work  that  uses  back¬ 
tracking  to  generate  a  test  input  that  executes  one  given 
path  (that  may  be  known  to  contain  a  bug)  [13, 16].  In  con¬ 
trast,  CUTE  attempts  to  cover  all  feasible  paths,  in  a  style 
similar  to  systematic  testing.  Moreover,  this  initial  work  did 
not  address  inputs  that  are  memory  graphs.  Visvanathan 
and  Gupta  [28]  recently  proposed  a  technique  that  gener¬ 
ates  memory  graphs.  They  also  use  a  specialized  symbolic 
execution  (not  the  exact  execution  with  symbolic  arrays) 
and  develop  a  solver  for  their  constraints.  However,  they 
consider  one  given  path,  do  not  consider  unknown  code  seg¬ 
ments  (e.g.,  library  functions),  and  do  not  use  a  combined 
concrete  execution  to  generate  new  test  inputs. 

7.  DISCUSSION 

We  next  discuss  the  advantages  of  using  CUTE  over  tra¬ 
ditional  symbolic  execution  based  testing  approaches. 

Pointer  casting  and  arithmetic 

CUTE  often  has  an  advantage  over  static  analysis  in  rea¬ 
soning  about  linked  data.  For  example,  to  determine  if  two 
pointers  point  to  the  same  memory  location,  CUTE  simply 
checks  whether  their  values  are  equal  and  does  not  require 
an  alias  analysis  that  may  be  inaccurate  in  the  presence  of 
pointer  casting  and  pointer  arithmetic.  For  example,  for  the 
following  C  program: 

struct  foo  {  int  i;  char  c;  }; 

void  *  memset (void  *s,char  c,size_t  n)  { 

for(int  i=0; i<n; i++)  ((char  *)s)[i]=c;  return  s;  } 
bar  (struct  foo  *a)  { 

if  (a  &&  a->c  ==  1)  { 

memset (a, 0,sizeof (struct  foo)); 
if  (a->c  ! =  1)  {  ERROR;  }}} 

a  fully  sound  static  analysis  should  report  that  ERROR  might 
be  reachable.  However,  such  a  sound  static-analysis  tool 
would  be  impractical  as  it  would  give  too  many  false  alarms. 
More  practical  tools,  such  as  BLAST  [14],  report  that  the 
code  is  safe  because  a  standard  alias  analysis  is  not  able 
to  see  that  a->c  has  been  overwritten.  In  contrast,  CUTE 
easily  finds  a  precise  execution  leading  to  the  ERROR.  This 
kind  of  code  is  often  found  in  C  where  memset  is  widely  used 
for  fast  memory  initialization. 


Library  functions  with  side-effects 

The  concrete  execution  of  CUTE  helps  to  remove  false 
alarms,  especially  in  the  presence  of  library  function  calls 
that  can  have  side-effects.  In  the  above  code,  for  example,  if 
the  function  memset  is  a  library  function  with  no  source  code 
available,  static-analysis  tools  have  no  way  to  find  out  how 
the  function  can  affect  the  global  heap.  In  such  situations, 
they  definitely  give  false  alarms.  However,  CUTE  can  tackle 
the  situation  as  it  can  see  the  side-effect  while  executing  the 
function  concretely. 

Approximating  symbolic  values  by  concrete  values 

CUTE  combines  the  concrete  and  symbolic  executions  to 
make  them  co-operate  with  each  other,  which  helps  to  han¬ 
dle  situations  where  most  symbolic  executors  would  give  un¬ 
certain  results.  For  example,  consider  testing  the  function  f 
in  the  following  C  code: 

g(int  x)  {  return  x*x+(x"/,2)  ;  } 

f(int  x,  int  y)  {  z=g(x) ;  if  (y  ==  z)  {  ERROR;  }  } 

A  symbolic  executor  would  generate  the  path  constraint 
y=x*x+(x"/,2)  that  is  not  in  a  decidable  theory.  Thus,  it 
cannot  say  that  ERROR  is  reachable  with  guarantee.  On  the 
other  hand,  suppose  that  CUTE  starts  with  the  initial  in¬ 
puts  x=3,y=4.  In  the  first  execution,  since  CUTE  cannot 
handle  the  symbolic  expression  x*x+(x"/t2),  it  approximates 
z  by  the  concrete  value  3*3+(37.2)  =  10  and  proceeds  to  gen¬ 
erate  the  path  constraint  y!=10.  Therefore,  by  solving  the 
path  constraint  CUTE  will  generate  the  inputs  x=3,y=10  for 
the  next  run  which  will  reveal  the  ERROR. 

Black-box  library  functions 

The  same  situation  arises  in  the  above  code  if  g  is  a  library 
function  whose  source  code  is  not  available.  A  symbolic  ex¬ 
ecutor  would  generate  the  path  constraint  y=g(x)  involving 
uninterpreted  function  and  would  give  a  possible  warning. 
However,  CUTE  in  the  same  way  as  before  generates  an 
input  leading  to  the  ERROR. 

Lazy  initialization 

One  can  imagine  combining  symbolic  execution  with  ran¬ 
domization  in  several  ways.  CUTE  commits  to  concrete 
values  before  the  execution.  Another  approach  would  be  to 
use  full  symbolic  execution  and  generate  concrete  values  on 
demand  [27].  However,  this  approach  does  not  handle  black¬ 
box  library  functions,  executes  slower  as  it  needs  to  always 
check  if  data  is  initialized,  and  cannot  “recover”  from  bad 
initialization  as  this  example  shows: 

f(int  x)  (z=x*x+(x702)  ;  if  (z==8)  {ERROR;  }  if  (x==10)  {ERROR;  }} 

After  executing  the  first  if  statement,  a  lazy  initializer  will 
initialize  x  to  a  random  value  in  any  run  since  it  cannot  de¬ 
cide  the  path  constraint  x*x+(x'/,2)=8.  Thus,  it  would  not 
be  able  to  take  the  then  branch  of  the  second  if.  CUTE, 
however,  would  generate  x=10  for  the  second  run  as  it  si¬ 
multaneously  executes  both  concretely  and  symbolically. 

8.  CONCLUSION 

Our  work  shows  that  approximate  symbolic  execution  for 
testing  code  with  dynamic  data  structures  is  feasible  and 
scalable.  Moreover,  we  have  shown  how  to  efficiently  gen¬ 
erate  dynamic  data  structures  by  incrementally  adding  and 


removing  a  node,  or  by  aliasing  two  pointers.  While  we  de¬ 
scribed  an  implementation  for  C,  we  have  also  developed 
an  implementation  for  the  sequential  subset  of  Java.  We 
are  currently  investigating  how  to  test  programs  with  con¬ 
currency  using  a  similar  method.  We  are  also  investigating 
the  application  of  the  technique  to  find  algebraic  security 
attacks  in  cryptographic  protocols,  and  security  breaches  in 
unsafe  languages. 
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